Subject: APPN DLUR-3b draft spec available

From: "Ed Tremblay (254-5515)" <[email-masked]>
Date: Thu, 6 Jan 94 11:26:13 EST

The DLUR architecture document has been updated and is available by
anonymous FTP to ibmstandards.cary.ibm.com under the name of
aiw/sig/dlur/dlur3b.psbin - the file is a PostScript file, but treat it
as binary when you get it and print it.

The items added in DLUR-3b are:

** 1) revised formats appendix

      A problem was found in testing which occurred because everyone
      was not using the same formats document.  Some were using the
      open formats (GA27-3136-13) and others - including myself - were
      using the licensed formats (LY43-0081-1).

      We believe that all DLUR/S implementers should use the open
      formats.  Currently the DLUR/S formats appendix is based on the
      licensed formats; draft DLUR-3b will have formats based on the
      open formats document.  Also the formats updated for DLUR/S will
      be placed in the open formats document.

      The changes to the open formats document will go beyond those
      formats actually changed by the architecture, based on a first
      pass I've made comparing the RUs and CVs in the appendix to their
      counterparts in the open and licensed formats documents:

   a) the following RUs and CVs already appear in the open formats and
      in the appendix (these will be modified in the appendix to remove
      any licensed material):

           ACTPU
           RSP(ACTLU)
           CV 0E
           CV 46

   b) the following RUs and CVs do not appear in the open formats but
      appear in the appendix (these will be modified in the appendix
      to remove any licensed material and added to the open formats):

           SESSEND (format 3 only will be defined in the open formats)
           SESSST  (format 3 only)
           CV 2A

   c) the following RUs and CVs do not appear in the open formats or
      in the appendix (these will be added to the appendix and the
      open formats):

           REQDISCONT
           CV 23  (format 2 only)
           CV 25
           CV 30
           CV 31
           CV 43

   d) the following RUs and CVs appear in the open formats but not
      in the appendix; licensed material is used by DLUR/S (these will
      be added to the appendix and updated in the open formats):

           CV 0C

** 2) clarified DLUR CV X'0C' processing

      As part of the format mismatch cleanup, the licensed version of
      CV X'0C' will be included in the open formats.  In the
      +RSP(ACTLU) section of the document (section 8.1.2):

    a) where there is a reference currently to an extended BIND
       indicator, it will specifically reference CV0C byte 7, bits 4 and
       6 (both will be checked)

    b) where there is a reference currently to a network-qualified names
       indicator, it will specifically reference CV0C byte 7, bit 5

    c) there will be a new reference to the SESSST support indicator at
       CV0C byte 7, bit 2, pointing out that if the DLUR should set
       this bit on, regardless of its value when received by the DLUR

** 3) clarified forced DACTPU processing (DLUS doesn't wait to send
      RSP(DACTPU) to SSCP)

      The figures describing the forced SSCP-PU/SSCP-LU deactivation
      flows are incorrect.  The figures currently show the DLUS
      waiting to receive a RSP(DACTPU) from the DLUR before forwarding
      the response to the SSCP; however, the DLUS does not wait but
      builds and sends a RSP(DACTPU) to the SSCP right after sending
      the DACTPU request to the DLUR.

      This means that additional processing must be described for the
      cases where:

      - the RSP(DACTPU) sent by the PU arrives at the DLUS (which has
        already sent a different copy to the SSCP)

      - the RSP(DACTPU) sent by the PU arrives at the DLUR, but the
        CP-SVR pipe to the DLUS is being deactivated (DLUS has already
        decided that there are no other SSCP-PU sessions at the time it
        built its own RSP(DACTPU)

      The changes include the following:

      a) In the SSCP-PU/SSCP-LU Session Deactivation (DLUS-Initiated)
         section, additional processing will be added to the
         description of forced deactivation:

         i) After sending the encapsulated DACTPU to the DLUR, the
            DLUS will build a RSP(DACTPU) and forward it to its SSCP.

        ii) Upon receipt of the RSP(DACTPU) from the DLUR, the
            DLUS will discard the RSP(DACTPU), having already sent one
            to the DLUS.  It will also discard a SESSEND if one is sent
            by the DLUR.

       iii) Upon receipt of the RSP(DACTPU) from the PU, the
            DLUR will discard the RSP(DACTPU) if its CP-SVR pipe has
            been or is being deactivated by the DLUS.

      b) The figures in error will be corrected (figures 5-12, 6-11).

** 4) added CPname as an identifier for a single DLUR-serviced internal
      PU

      There is a requirement to allow CPname to be used instead of
      IDBLK/IDNUM to identify one (and only one) of a DLUR's internal
      PUs; all other internal PUs serviced by a DLUR will continue to
      be identified by IDBLK/IDNUM.

      Just as IDBLK/IDNUM information will be carried in a DLC
      signalling information subfield, a new subfield will be
      architected for CP name.  The definitions will wind up as
      when CV X'4691' = INTPU, CV X'4692' will carry IDBLK/IDNUM and
      CV X'4693' will carry CPname.

** 5) corrected CPSVRMGR session rejection processing (DLUS always
      deactivates the pipe upon CPSVRMGR session rejection)

      The description of CPSVRMGR session rejection processing is
      incorrect in section 5.5.2 (it is correct elsewhere in the
      document).  It states that the rejecting node will issue an UNBIND
      for its conwinner CPSVRMGR session if there are no pending/active
      encapsulated sessions on the pipe.  The correction will state that
      the DLUS, not the rejecting node (which could be the DLUR), will
      issue an UNBIND for its conwinner and conloser sessions if there
      are no pending/active encapsulated sessions on the pipe.

** 6) specified sense codes associated with SSCP-PU and SSCP-LU traffic
      arriving at the DLUR when the session with the SSCP is inactive

      Questions have arisen about the ambiguous sense code in figure
      6-12 (0857 xxxx).  While choosing a sense code to propose for
      DLUR to use, I noticed that the prose incorrectly indicated
      that the DLUR use the same code for SSCP-PU traffic.  So I'm also
      proposing a sense code for the PU case:

      a) When the DLUR receives SSCP-LU data from the SLU while the
         SSCP-LU session is inactive, the document indicates that a
         sense code of X'0857 xxxx' will be returned.  This will be
         corrected to state X'0857 0003' (the SSCP-SLU session is
         inactive).

      b) When the DLUR receives SSCP-PU data from the SLU's PU while
         the SSCP-PU session is inactive, the document gives no
         indication as to which sense code to return.  This will be
         corrected to specify X'087C 0000' (SSCP-PU session inactive).

** 7) added section describing PU reactivation after deactivation,
      including effects on active LU-LU sessions

      There has been a question about how to handle LU-LU sessions left
      active during SSCP-PU deactivation (due to ANS=CONT) when the PU
      is reactivated with ANS=STOP.  Since there isn't a specific
      section on PU reactivation, I'm adding the following in a new
      section:

        If a PU was initially activated with ANS=STOP, the deactivation
        process will deactivate any active LU-LU sessions associated
        with the PU.  Then when the PU is reactivated, whether with
        ANS=STOP or ANS=CONT, there are no associated sessions to
        handle.

        If, however, the PU is initially activated with ANS=CONT, the
        deactivation process will not tear down the active LU-LU
        sessions.  If the PU is reactivated with ANS=CONT, the LU-LU
        sessions stay up and will be identified to the new SSCP in a
        CV X'2A' included in RSP(ACTLU) by the DLUR. If the PU is
        reactivated with ANS=STOP, the DLUR will deactivate any active
        LU-LU sessions as part of the PU activation process.

I'm requesting comments on these items to be received no later than
January 19.  If there is a consensus for approval at that time, I will
consider these items to be at AD status as of January 20.

I'm going to start work on DLUR-4 with a projected availability date
at the end of January.  This should be the draft for which AP status
will be requested.

Ed Tremblay